Python 3.14 defaults to the "forkserver" multiprocessing start method,
instead of the previous "fork" default. This new default causes all
sorts of problems for us.

The hardest to fix one, which made me throw in the towel on trying to
get things working with "forkserver", is that pytest's `pytester`
fixture defaults to running the new pytest session in the current
process, rather than from a subprocess, and we're using `capfd` to
capture the stderr. With the "fork" method and the "spawn" method, the
new process inherits whatever the parent process's stderr (fd 2) is
pointed to at the time when the new process is started, but with
"forkserver" the server gets created once and then reused, and all
future children have their stderr pointed wherever the first child
process's stderr was pointed to.

There's other issues too. We leak semaphores because the monitoring
process winds up creating an unnecessary `Event` and `Queue` that it
ignores in favor of the ones passed to its entry point. That could be
fixed by creating those lazily instead of at import time, but that leads
to pickling failures because the `multiprocessing.connection` module
gets created lazily, and `pytester` unloads modules that were loaded by
the tests, which leads to two different copies of that module getting
loaded, with the old module still referenced by some things.

We could work around all of this in our test suite, but using our plugin
along with the `pytester` fixture is a reasonable use case that end
users might want, if they're trying to use `pytest-pystack` to test
their own pytest plugin.

The most reasonable solution is for us to detect when "forkserver" would
be used, and to use "spawn" instead in those cases.